Many storage networks may implement data replication and/or other redundancy data access techniques for data loss protection and non-disruptive client access. For example, a first storage cluster may comprise a first storage controller configured to provide clients with primary access to data stored within a first storage device and/or other storage devices. A second storage cluster may comprise a second storage controller configured to provide clients with primary access to data stored within a second storage device and/or other storage devices. The first storage controller and the second storage controller may be configured according to a disaster recovery relationship, such that the second storage controller may provide failover access to replicated data that was replicated from the first storage device to a secondary storage device, owned by the first storage controller, but accessible to the second storage controller (e.g., a switchover operation may be performed where the second storage controller assumes ownership of the secondary storage device and/or other storage devices previously owned by the first storage controller so that the second storage controller may provide clients with failover access to replicated data within such storage devices).
In an example, the second storage cluster may be located at a remote site to the first storage cluster (e.g., storage clusters may be located in different buildings, cities, thousands of kilometers from one another, etc.). Thus, if a disaster occurs at a site of a storage cluster, then a surviving storage cluster may remain unaffected by the disaster (e.g., a power outage of a building hosting the first storage cluster may not affect a second building hosting the second storage cluster in a different city).
In an example, two storage controllers within a storage cluster may be configured according to a high availability configuration, such as where the two storage controllers are locally connected to one another and/or to the same storage devices. In this way, when a storage controller fails, then a high availability partner storage controller can quickly takeover for the failed storage controller due to the local connectivity. Thus, the high availability partner storage controller may provide clients with access to data previously accessible through the failed storage controller.
Various replication and synchronization techniques may be used to replicate data (e.g., client data), configuration data (e.g., a size of a volume, a name of a volume, etc.), and/or write caching data (e.g., cached write operations) between storage controllers and/or storage devices. In an example, a storage operation, targeting the first storage device, may be split and replicated as a replicated storage operation targeting the secondary storage device. Upon successful commitment of the storage operation to the first storage device and the replicated storage operation to the secondary storage device, a complete notification may be provided to a host that issued the storage operation. In this way, synchronous replication may be achieved. In another example, snapshots of a source volume (e.g., within the first storage device) may be used to replicate the source volume to a destination volume (e.g., within the secondary storage device). For example, a base snapshot of the source volume may be used to initially create the destination volume. A current incremental snapshot of the source volume may be used to replicate changes made to the source volume since the base snapshot or since a last incremental snapshot. Unfortunately, a client may merely have an interest in replicating a portion of the volume, such as a subdirectory (e.g., or any other arbitrary portion of the volume), and thus volume level replication techniques may waste computing resources and bandwidth replicating the entire volume such as data with which the client does not have an interest in replicating. Such inefficiencies become even more problematic as the size of volumes increase.